This is a useful shortcut to determine whether a `User` instance is the
current default user. The previous way of determing this was to retrieve
the default user from the collection `User.collection.get_default()` and
manually compare it with the `User` instance.

Uses the `tabulate` package to create a nicely formatted table as is
used in many other `verdi` commands already. The results are ordered by
the users emails.

Each profile can define which user in its storage backend should be
considered the default. This is necessary because each ORM entity, when
created, needs to specify a `User` object and we don't want the user to
always have to explicitly define this manuallly.

The default user for a profile is stored in the configuration file by
the email of the `User` object. However, in a loaded storage backend,
this default user is also cached as the `User` object. This means that
when the default user is changed, it should be changed both in the
configuration file, but if a storage backend is loaded, the cache should
also be invalidated, such that the next time the default user is
requested, the new one is properly loaded from the database.

Since this change affects both the configuration as well as the
currently loaded storage, the `set_default_user_email` is added to the
`Manager` class, since that controls both. It calls through to the same
method on the `Config` class, which is responsible for updating the
`Config` instance in memory and writing the changes to disk. Then the
manager resets the default user on the storage backend, if any is
loaded.

The `verdi user set-default` command is updated to use the new method. A
test is added for the command, which didn't exist yet. The command is
updated to use `Manager.set_default_user_email` even though it could use
`Config.set_default_user_email` since the Python interpreter will shut
down immediately after anyway. However, the test would fail if the
latter would be used, since the loaded storage backend would not have
been updated, which is used by `User.collection.get_default()`. This
demonstrates why in active Python interpreters only the method on the
manager should be used. A warning is added to the docstring on the
configuration class.

This way it is guaranteed that the same types are being used, which were
actually different. The `--set-default` flag now also gets its default
from the current value on the selected user, just as is done for the
other properties.

The user options `--first-name`, `--last-name` and `--institution` in
the `verdi quicksetup/setup` commands were recently made required but
did not provide a default. This would make creating profiles
significantly more complex than always needed. For simple test and demo
profiles the user might not necessarily care about these user details.

Here we add defaults for these options. Even for production profiles
this is a sensible approach since these details can always be freely
updated later on with `verdi user configure`. This is also the reason
that the `--email` does not provide a default because that can not be
changed later on.